WASI 0.2 GA: WebAssembly componible de verdad

javi
Bloques modulares metálicos ensamblándose representando componentes componibles

WASI 0.2 Preview 2 alcanzó GA en enero de 2024, y con ello, el Component Model de WebAssembly. Este es momento decisivo: WebAssembly fuera del navegador deja de ser experimento para ser plataforma capaz de ejecutar código polyglot componible. Este artículo cubre qué cambia prácticamente, cuándo elegir Wasm server-side, y qué casos ya son viables hoy.

Qué es el Component Model

Antes de 0.2, WebAssembly server-side era WASI Preview 1: syscalls Unix-like. Cada módulo era isla — integraciones eran manuales.

Preview 2 Component Model añade:

  • WIT (WebAssembly Interface Types): definición de interfaces cross-language.
  • Components: unidad de composición (como crates Rust o npm packages, pero multi-language).
  • Dependency injection: componentes consumen interfaces, plugable.
  • Type safety across language boundaries.

Resultado: puedes escribir un component en Rust, otro en Go, otro en JavaScript, y componerlos sin glue code manual.

WIT example

package example:greeter@1.0.0;

interface greeter {
    greet: func(name: string) -> string;
}

world host {
    export greeter;
}

Cualquier lenguaje que compile a Wasm component puede implementar o consumir esto.

Casos reales viables

Edge serverless

Fastly Compute, Cloudflare Workers (con Wasm), Fermyon usan Wasm server-side para:

  • Low cold-start (<1ms).
  • Sandboxing strict.
  • Portabilidad multi-runtime.
  • Scaling masivo.

Plugins para apps host

Un app host puede cargar components Wasm como plugins:

Plugins portable entre runtimes sin recompilar.

Embedded y IoT

Wasm runs en devices con kilobytes de memoria:

  • wasm-micro-runtime (WAMR): para IoT.
  • Firmware customizable sin reflashing.
  • Sandbox para código untrusted.

Runtimes principales

Wasmtime es el default más seguro. Los otros tienen focos específicos.

Lenguajes compatibles

Maturity variable:

  • Rust: ciudadano de primera (componentize-rs, cargo-component).
  • Go: TinyGo soporta (limitaciones vs Go full).
  • C/C++: via wasi-sdk, mature.
  • JavaScript: via Javy (para edge), Componentize-JS.
  • Python: experimental via componentize-py.
  • .NET: soporte emergente.
  • Java: via WASI-libc, less common.

Rust es el path menos fricción. Otros están cerrando gap.

Un component en Rust

// cargo-component new hello
cargo component build --release

Configure WIT, implement interface, compila a .wasm component. Usable desde cualquier host Wasm que soporte CM.

WASI 0.2 interfaces

Provee interfaces estándar:

  • wasi:filesystem: FS access.
  • wasi:sockets: TCP/UDP.
  • wasi:http: HTTP client/server.
  • wasi:clocks: time.
  • wasi:random: RNG.
  • wasi:cli: stdin/stdout/env.

Código puede targetar estas interfaces; runtime las implementa según contexto.

Vs Docker / containers

¿Wasm reemplaza containers? Depende:

Aspecto Wasm component Container
Cold start <1ms 100ms-1s
Tamaño KB-MB MB-GB
Aislamiento Muy fuerte Bueno
Ecosistema Emergiendo Masivo
Multi-language Sí (via CM) Sí
OS access Limitado (safer) Full

Para edge functions, serverless, plugins, Wasm gana. Para apps tradicionales o legacy, containers siguen siendo default.

Kubernetes y Wasm

Integraciones:

  • krustlet: kubelet para Wasm (legacy).
  • runwasi: containerd runtime para Wasm.
  • kwasm: operator para enable Wasm en K8s nodes.

Ejecutar Wasm directamente en K8s sin containerizarlos es posible hoy.

Limitaciones

  • Ecosistema aún emergente: muchas libraries faltan.
  • Debugging: más difícil que native o container.
  • Async story: mejora pero no terminada.
  • Performance: cerca de native pero no igual.
  • GC languages: menos eficientes cuando target Wasm.

Casos donde hoy usar Wasm

  • Edge functions con cold start crítico.
  • Plugins seguros para apps host.
  • Sandboxing de código untrusted.
  • Portabilidad cross-platform (code corre igual en Mac, Linux, Windows, ARM, x86).

Casos donde esperar

  • Apps web tradicionales: sin ventaja clara sobre containers.
  • Databases: runtime Wasm no madura para stateful pesado.
  • Heavy computation: native o GPU siguen siendo mejores.

Futuro

Roadmap near-term:

  • Más languages con component model support.
  • WASI 0.3: async, threads.
  • Más runtime support: Cloudflare Workers full Component Model.
  • Unified tooling: ecosystem consolidation.

Dirección clara pero varios años para maturity comparable a containers.

Conclusión

WASI 0.2 GA es milestone significativo. El Component Model resuelve portabilidad cross-language que frenaba adoption. Para edge functions, plugins seguros, y portabilidad extrema, Wasm server-side ya es viable hoy. Para apps tradicionales, no reemplaza containers — los complementa. Equipos que construyen edge functions o plataformas con plugins deben evaluar Wasm. Para el resto, es tecnología a seguir pero no urgente adoptar. La convergencia de Wasm con Kubernetes y containerd es otra señal de maturity — ecosistema se está conectando, no fragmentando.

Síguenos en jacar.es para más sobre WebAssembly, edge computing y arquitecturas modernas.

Entradas relacionadas